fix(ui): resolve interactive selections by index, not display text - #68

SelectGroup bound survey.Select to a string and recovered the group with
FindGroupByDisplay. Two groups with the same name in different directories
render identically, so the lookup returned the first match regardless of which
row the user highlighted - highlighting the second elevated into the first.
Sorting a copy never fixed that; it only made the wrong answer deterministic.

SelectGroup now binds an int and resolves through resolveGroupSelection,
matching SelectRole and SelectRequest. The sort becomes SliceStable so
colliding rows keep their input order.

Tests:
- TestResolveGroupSelection_DuplicateDisplayStrings pins the index path; it
  fails when the resolver is reverted to a display lookup.
- TestSortGroupsForDisplay_Ordering replaces the collision test, dropping its
  tautological FindGroupByDisplay round-trip and claiming only what it pins:
  display ordering plus a full-snapshot caller-slice immutability check.
- TestSelect{Target,Sessions,Group,Role,Request}_Non{TTY,Interactive}EmptyList
  pin the non-interactive guard ahead of the empty-list guard; all five fail
  when the guards are swapped.
- Role option/role parallelism and a length assertion; exact-match assertion
  in the request timestamp test.

Docs: CHANGELOG Fixed entry; mutation-ledger UI-02/06/08 line references
repointed and UI-02's narrative corrected to list ordering only.

SelectTarget rendered BuildOptions(targets) - a sorted string slice - and then
recovered the answer with FindTargetByDisplay against the caller's unsorted
slice. FormatTargetOption carries no ID, so two eligible targets with the same
workspace name and role in different subscriptions or accounts render
identically; the lookup returned the first match whatever the user highlighted,
and because the rendered and searched slices were in different orders the two
could disagree even without a collision. Wrong-target elevation either way.

SelectTarget now renders from sortTargetsForDisplay and resolves through
resolveTargetSelection by index, matching SelectGroup/SelectRole/SelectRequest.
The sort is stable, so colliding rows keep their input order. Guard order is
unchanged: non-interactive still fires before the empty-list check.

SelectSessions keeps its display-text lookup and gains a comment saying why:
every option string embeds the session ID, so collisions are unreachable.

Tests:
- TestResolveTargetSelection_DuplicateDisplayStrings pins the index path; it
  fails when the resolver is reverted to a display lookup.
- TestResolveTargetSelection_OutOfRange mirrors the group equivalent.
- TestSortTargetsForDisplay_Ordering pins display ordering, stable ordering of
  colliding rows, and caller-slice immutability.

Docs: CHANGELOG Fixed entry; mutation-ledger production-changes row (not an
audit row - found by the PR7 review), UI-06 line reference repointed, and both
FindTargetByDisplay and FindGroupByDisplay noted as deletion candidates.

The unified selector behind plain `grant`, `grant --groups` and
`grant favorites add` still bound survey.Select to a string and looked the
answer back up with findItemByDisplay. formatSelectionItem carries no ID, so
two Entra ID groups with the same name in different directories render
identically and the lookup returned the first match regardless of which row the
user highlighted — elevating into the wrong group.

Bind the selected index instead and recover the item with a bounds-checked
resolveSelectionItem, mirroring resolveGroupSelection/resolveTargetSelection.
Out-of-range indexes error rather than clamp. buildUnifiedOptions now sorts
stably so the options slice and the sorted items slice stay index-aligned.

The index fixes were only pinned by unit tests over the resolve* helpers, so
reverting SelectTarget/SelectGroup/SelectItem to display-string resolution left
the whole suite green. These tests drive the real survey prompt over a real
pseudo-terminal and assert the highlighted row is the one that comes back,
including after the user types a filter.

The pty is allocated with raw /dev/ptmx plus the TIOCSPTLCK/TIOCGPTN ioctls so
no new Go module dependency is needed. Linux-only by file name; CI's Windows
leg never compiles these files.

ui.SelectGroup, ui.FindGroupByDisplay and ui.FindTargetByDisplay had zero
production callers: the group path users actually reach (`grant --groups` and
plain `grant`) goes through cmd's unified selector, and both Find* helpers were
superseded by index resolution. Removing SelectGroup orphans
sortGroupsForDisplay and resolveGroupSelection, which existed only to serve it,
so they go too, along with the tests that only covered the deleted code.

ui.SelectTarget stays — it is live via `grant env`. FormatGroupOption and
BuildGroupOptions stay — cmd/list.go uses them.

Both sorted selectors were only exercised with 4-element fixtures. Go's pdqsort
delegates to insertion sort below n=12, which is incidentally stable, so
swapping sort.SliceStable for sort.Slice passed the whole suite. The new
fixtures use 15 entries in 5 colliding groups and assert that items rendering
identically keep their input order, which kills that mutation in both places.

The ledger credited the two index fixes to tests over the extracted resolve*
helpers, which do not pin the wiring — reverting the selectors to
display-string resolution left the suite green. Name the pty tests instead, and
add rows for the unified-selector fix, the dead-code deletion and the widened
sort fixtures.

A test comment claimed survey.Select cannot be driven from a test; it can, and
now is. The SelectSessions comment asserted collisions are impossible; that is
an assumption about the SCA API, so state it as one and note that
FindSessionByDisplay fails open if it breaks.

CHANGELOG: collapse the two selector lines into one that covers both the
unified selector and grant env's target selector.